Community Breakfast October 2011 - Best Practices for Working with your Dev Team
Hosted by UserVoice Notes lovingly written by causeit. What works in your formal process with developers? What doesn't? Many attendees related that the formal processes for accessing developers in their companies don't work particularly well other than for establishing priorities, and leans on more personal connections to get results and build relationships. Out of the conversation, a number of different questions arose, providing a bit of what-to-ask-after if you're interviewing a company to work with them or brainstorming with your team to increase communication:*How to work with management to re-prioritize? *How to communicate with the community about the problems they may experience when the developer can’t attend to it immediately? *Evan: how do you create the middleman to prioritize tickets, etc—so that the developers respect that prioritization? One attendee shared that running social media listening post reports and ticket reports quantifying how many people are reporting an issue is a great way to prioritize by community impact. Storify reports from Facebook and Twitter are a great way to show what features get feedback one way or another. How do you build rapport with your development team? It also became clear that a lack of transparency about development goals/CM goals makes it hard for either side to ‘get’ each other. Jeremy and MJ from Causeit mentioned a focus on bringing people into meetings which aren’t ‘theirs,’ like developers in strategy meetings and vice versa. CMs focused on supporting internal development communities seem to report more succes than community managers viewing only external communities (like customers) as true communities. For example, community managers who write user stories for developers can make a big difference for their internal and external communities simultaneously, while building rappot. Another community manager lets her developers know about their wins from/for the community so that they have the experience of acknowledgment and positive feedback which puts negative feedback in perspective. How can you ease work with remote team members? Again, many community managers emphasized reaching out to your offsite developers as another community you ‘manage’ so that you can ensure you’re in the conversations that matter to your developers. Ideas like welcome notes when they join the team, CC'ing people on strategy (and not just bug/feature emails) and reaching out for online social events (think chatrooms and Google+ meetups) were all suggested. That's great, but how do you build a functional internal development community? (A brief brainstorm.) *Weekly meetings *Met devs on their terms: chat, etc. *Happy hours *Scrums *Using Campfire *Transparency *Developers: having them ‘get’ the use cases *Using your CM chops to let the devs know what’s up for users—what matters to them. Do you use Yammer, or other community tools? CMs raved about a couple of simple strategies they've found to build up the fabric of their intenral development communities: *Yammer *Jive *Private Facebook groups for simple sharing *Status feeds, as in TeamworkPM When new features are wanted or needed by community, and only some transparency is possible, what can you do? Evan and other attendees suggest bringing the angry tweets and feedback from customers to the development and management teams to create a case for action, with reminders to the development team that the users have little to no access to what’s going on in the development plan. In other words, managers and developers who see customer complaints and, exasperated, throw up their hands and say 'we're doing all we can' can use gentle (or firm) reminders that end users often don't know what is being done or why their request/bug is being prioritized the way it is. Other topics *How to deal with merged products/acquisition challenges? *How to bring transparency to CM? *How much truth can you tell your customer? When possible, immediate and clear response makes a big deal. *Time-boxing responses to feature requests, etc. *Using bugs or other breakdowns as a moment to connect with community and develop relationships *During DoS attacks etc, direct the energy and anger where it’s deserved, like at the hackers.